15장. 중간 개발 루프

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 15장 (pp. 324~357). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

내부 루프가 숨 쉬듯 빠르게 돌아간다면, 중간 루프는 몇 시간에서 며칠에 걸친 세션 전환을 다룬다 — 매번 백지로 돌아가는 AI 수셰프에게 이전 세션을 어떻게 물려줄 것인가의 문제다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• AI 어시스턴트가 세션마다 기억을 잃는다는 제약이 왜 중간 루프에서만 특별히 문제가 되는지, 내부 루프·외부 루프와 주기를 구분해 설명한다.
• 골든 룰 문서화·메멘토 메서드·코드베이스 재설계·멀티에이전트 분리라는 예방 기법 네 가지를 순서대로 적용한다.
• 에이전트 간 경합과 코드 열화라는 두 가지 감지 대상을 구분하고, 각각의 조기 경보 신호를 식별한다.
• 트레이서 불릿으로 AI의 한계를 스트레스 테스트하고, 언제 수동 코딩으로 전환해야 하는지 판단한다.
• 워크플로 자동화의 보상을 N·K/t·σ 공식으로 설명하고, 옵셔널리티 경제학이 왜 변화 비용을 낮추는 모듈형 아키텍처를 요구하는지 논한다.

전체 흐름도

예방 (세션 전환에도 살아남는 것 만들기)
   §2.1 골든 룰 문서화(AGENTS.md) → §2.2 메멘토 메서드(외부 메모리)
        → §2.3 AI를 위한 공장 재설계 → §2.4 비용의 현실
        → §2.5 멀티에이전트 → §2.6 교차 오염 방지 → §2.7 유휴 에이전트 활용
                              │
                              ▼
감지 (폭발 전에 경고 포착)
   §3.1 에이전트 간 경합 감지 ── §3.2 코드 열화 감지(엘드리치 호러 코드베이스)
                              │
                              ▼
교정 (재해 복구)
   §4.1 트레이서 불릿 스트레스 테스트 → §4.2 워크플로 자동화 투자
        → §4.3 옵셔널리티 경제학(N·K/t·σ)
                              │
                              ▼
§5 결론 — 7가지 핵심 실천 사항 · 다음 장(외부 개발 루프) 예고

0. 용어 사전

참고 — 위쪽 다섯 개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 3장·7장·8장·9장·10장을 먼저 보라.

1. 중간 루프란 무엇인가 — 내부 루프와 외부 루프 사이

내부 루프가 숨 쉬듯 자연스럽게 이어지며 빠르게 돌아간다면, 중간 루프는 전혀 다른 종류의 주의를 요구한다. 중간 루프는 몇 시간마다 또는 며칠에 걸쳐 이루어지는 세션 간 전환과 정보 인계를 다룬다. 인간 팀원은 어제 했던 일과 대화를 기억하지만, AI 어시스턴트는 세션이 끝날 때마다 벽장 속으로 들어가 모든 것을 잊어버리는 존재다. 새 대화를 시작하면 AI는 완전히 백지 상태로 돌아가고, 몇 시간·몇 분 또는 며칠간 쌓은 모든 맥락·뉘앙스·제약 조건이 사라진다.

이 장의 저자들은 독자를 "기억력에 한계가 있는 수셰프들을 거느리면서 프로젝트를 이끌어가야 하는 유일한 책임자"로 규정한다. 새로운 작업이나 새로운 세션을 시작할 때마다 밑바닥부터 지식을 쌓는 대신, 이전 세션의 결과를 자연스럽게 이어받을 수 있게 전략을 짜야 한다. 이 장은 그 전략을 예방·감지·교정이라는 세 단계로 구성해, 프로젝트의 흐름이 끊기지 않게 유지하면서 동시에 헤드 셰프의 정신적 안정도 지켜내는 방법을 다룬다.

세 루프의 경계를 먼저 분명히 해두면 이 장의 위치가 또렷해진다. 내부 루프(14장)는 분·초 단위로 도는 즉각적인 대화형 작업이고, 중간 루프(이 장)는 시간·일 단위의 세션 전환이며, 외부 루프(16장)는 주·달 단위의 전략적 방향이다. 내부 루프의 문제는 즉각 드러나지만, 중간 루프의 문제는 폭발하기 전까지 며칠 혹은 몇 주 동안 숨어 있다는 점이 이 장 전체를 관통하는 위기감의 근원이다.

2. 예방 — 세션이 바뀌어도 살아남는 것들

교대 시간에 수셰프들이 모든 것을 잊어버려도 궤도에서 벗어나지 않게 만드는 예방책은 네 겹으로 쌓인다. 가장 먼저 지속적인 메모리 시스템을 만들고, 그다음 AI가 잘 적응하도록 코드베이스 구조를 개편하고, 그 후에 멀티에이전트로 확장한다 — 이 순서 하나하나가 다음 단계의 토대가 된다.

2.1 골든 룰을 글로 적어두기

팀으로 일할 때는 규칙을 글로 적어야 한다. 수셰프와 라인 담당자(여기서는 AI)는 당신과 다른 곳에서 훈련받았을 수 있으므로, 명시적으로 알려주지 않으면 머릿속 규칙이 다를 수밖에 없고 AI는 당신의 마음을 읽을 수 없다. 이는 새로운 문제가 아니다 — 구글이 C++ 사용자에게 익셉션(exception) 던지기를 금지한 것도 상용 환경에서 아무도 캐치하지 못한 예외가 장애로 이어지는 것을 막기 위한 서면 규칙이었다. 스티브가 구글에 재직하던 동안 구글의 코딩 가이드는 28쪽에서 90쪽으로 늘어났는데, 이는 엔터프라이즈 환경에서 규칙이 얼마나 복잡해질 수 있는지를 보여준다.

그러나 모든 규칙을 다 적어둘 수는 없다. 콘텍스트 윈도, 어텐션 희석, AI의 지시 이행 한계 때문이다. 규칙 목록이 길어질수록 AI가 모든 규칙을 따를 가능성은 줄어든다 — 주방 벽에 붙인 종이가 커질수록 적고 싶은 규칙은 많아지고 글씨는 작아지며, 깨알 같은 글씨는 더 따르기 어렵다. 그래서 AI와 협업할 때는 항상 해야 하는 것과 절대로 해서는 안 되는 것만 정제한 골든 룰을 문서화하는 데 집중해야 한다. 예를 들면 다음과 같다.

• 전역 변수를 절대 사용하지 않는다.
• 키를 버전 관리에 절대 넣지 않는다.
• 항상 시크릿 매니저를 사용한다.
• 깊게 중첩된 함수는 피한다.
• 타입이 있는 언어에서는 와일드카드나 any 타입을 피한다.

2024년, 앤트로픽의 테크니컬 스태프인 캐서린 올슨은 "까다로운 작업을 하다 같은 실수를 계속 반복하면, 그 실수들을 작은 노트에 기록해둔다. 그런 다음 콘텍스트를 갱신하거나 프롬프트를 다시 쓸 때, 그 실수들을 다시는 하지 말라고 AI에게 상기시킨다"고 말했다. 이 노트들은 이제 코딩 에이전트용 AGENTS.md 파일(또는 그에 상응하는 것)로 체계화됐다. 모든 가이드라인과 규칙을 이런 파일에 정리해두면, AI와 대화할 때마다 그 규칙을 최우선으로 고려한다. 이렇게 규칙을 세심하게 큐레이션하는 것은 모델이 발전하면 나중엔 불필요해질 수도 있지만, 작은 모델이나 긴 지시를 따르기 어려워하는 AI를 다룰 때는 오랫동안 응답 일관성을 높이는 데 유용하다.

골든 룰을 세팅해도 AI 어시스턴트가 모든 것을 그대로 따를 것이라는 확신은 할 수 없다. 그래서 검증과 완화 작업이 추가로 필요하며, 서면으로 기록해둔 가이드라인은 규칙 준수 여부를 확인하는 근거이자 검증 단계의 기대치가 된다.

메모리에는 다양한 형태가 있다 — 프로젝트·사용자·전역 수준의 마크다운 문서(대화 시작 부분에 자동 삽입), 중요한 작업에서 AI의 주의를 환기시키려 인간이 수동으로 붙여 넣는 규칙, 여러 팀과 여러 AI가 장기간 협업하며 쌓은 규칙 모음 데이터베이스가 그것이다. 영구 메모리 시스템이 있고 워크플로가 그 메모리를 이미 학습한 상태라도, 가장 중요한 골든 룰은 메모리에서 가장 우선순위가 높은 자리에 직접 넣어야 하는 경우도 있다. AI와 도구가 발전하면 검증 작업은 점차 자동화되겠지만, 그때까지는 명확하게 규칙을 작성하는 것이 가장 강력한 예방 수단이다.

2.2 메멘토 메서드로 외부 메모리 만들기

세계적인 주방에서도 AI 도우미는 매일 리셋된다 — "AI들은 옷장 안에 들어갔다 다음 날 나왔을 때 모든 것을 잊어버린다." 며칠에 걸쳐 준비해야 하는 요리가 있다면 이 특성은 거대한 도전이 된다. 10장 §4가 다룬 콘텍스트 포화의 위험이 여기서 실전 문제로 돌아온다 — 스티브의 팀은 콘텍스트 윈도가 50%만 차 있어도 AI 모델들이 중요한 지시를 잊기 시작한다는 현상을 발견했다.

콘텍스트 포화에서 핵심은 아주 작은 작업조차 콘텍스트 윈도를 소모한다는 점이다. 에이전트는 겉보기에 사소한 변경이더라도 대량의 콘텍스트를 끌어와 작업하고, 윈도가 한계에 가까워지면 긴 대화를 몇 페이지로 요약하는 압축(compaction)을 시도한다. 압축 없이 세션을 얼마나 오래 유지할 수 있는지는 언어·도구의 견고함·AI가 프로젝트를 이해하는 데 필요한 작업량에 달려 있으며, 로그나 빌드 출력이 장황하면 압축까지의 주기는 몇 분 단위로 빨라질 수도 있다.

그래서 저자들은 가능할 때마다 선제적으로 콘텍스트를 정리한다 — 콘텍스트 잔여량이 20~50%에 가까워지면 AI에게 잠깐 멈추고 하고 있는 일을 문서화하라고 지시한다. 까다로운 작업 중에는 실수로 자동 압축이 실행되지 않도록 주의해야 한다. 자칫 중요한 콘텍스트가 유실될 수 있다. 추가 지시 사항까지 포함해 최신 계획 문서나 명세서를 마크다운 파일로 만든 다음에야 압축을 하거나 콘텍스트를 비운다.

이렇게 작성한 명세 파일들은 프로젝트를 계속 끌고 갈 수 있게 도와주는 외부 메모리 역할을 한다. 영화 〈메멘토〉의 주인공은 사고로 인한 단기 기억상실증 때문에 10~15분 이상 기억을 지속하지 못해 메모와 문신으로 자신의 기억을 외부화했다. 메멘토 메서드는 AI에게도 같은 원리를 적용한다 — 다음 세션에 무언가를 기억하게 만들려면 선제적으로 곳곳에 단서를 남겨야 한다. 서면 산출물을 만들고, 명확한 내용이 담긴 문서를 유지 보수하고, 세션 전환 시 이전 세션에 남아 있는 중요한 콘텍스트를 보존해야 한다.

저자들의 경험상 가장 실용적인 예방 전략은 세션 종료 전에 에이전트에게 자신의 상태를 외부화하도록 지시하는 것이었다 — "우리가 지금까지 했던 모든 작업의 진행 상황과 계획을 마크다운 파일에 적어서, 현재 상황을 기준으로 다시 작업을 시작할 수 있게 해줘"라는 간단한 프롬프트만으로 AI는 마크다운 파일이라는 원초적인 인공 메모리를 만들어낸다. 이 파일은 매우 중요하므로 어떤 세부 사항이 빠졌는지 검토하고 빠진 게 있다면 추가해야 한다.

2.3 AI를 위해 공장(코드베이스) 재설계하기

주방을 원활하게 운영하려면 정리를 잘하고 환경을 잘 설계해야 한다. 재료가 너무 높은 곳에 있거나 필수 용품이 여기저기 흩어져 있으면 안 된다. AI와 함께 더 많은 코드를 작성하면서, 우리는 어쩌면 AI 어시스턴트에게 장애물이 될 무언가를 부지불식간에 만들고 있을지도 모른다. 저자들은 잘 돌아가는 코드라도 리팩터링하는 것이 AI의 작업 효율을 높인다는 것을 다수의 사례로 체득했다 — AI를 달래는 것처럼 느껴지는 작업이지만 실제로 효과가 있다.

진은 작가용 워크벤치 툴을 유지 보수하며 어떤 파일이 에이전트가 한 번에 읽기에 너무 크다는 에러 메시지를 봤다. 그 파일은 2500줄이 넘었고, 에이전트는 파일 전체를 읽는 대신 grep으로 훑고 있었다. 진은 이 현상을 발견한 즉시 코드를 서로 다른 모듈로 옮기기 시작했다 — 200줄씩 띄엄띄엄 읽으며 퍼즐을 맞추는 대신, 에이전트가 진짜 해결하려는 문제에 더 가까이 다가갈 기회를 주기 위해서였다.

이 경험은 전문가 수준 바이브 코딩의 원칙을 부각시킨다 — AI 어시스턴트를 거슬러 코딩해서는 안 된다. AI에게 일을 맡기는 상황에서는 AI가 어려워할 방식으로 프로젝트를 구성해서도 안 된다. 실제로 어떤 큰 회사는 얼랭(경량 프로세스와 동시성을 지원하는 언어)에서 자바로의 마이그레이션을 고려하고 있었는데, 자바는 생태계가 풍부해 프런티어 모델의 학습 데이터가 방대하므로 AI 도구가 자바에서 더 잘 작동한다는 것을 관찰했기 때문이다 — 이미 많은 자원을 얼랭에 투자했지만, 현재 기술 스택이 AI의 결을 거스르는 형국이라 자바 이전이 작업 난도를 낮추는 결정이라 봤다.

이렇게 AI의 결에 맞춰 환경을 재정비하는 것은 자동차가 대량생산되기 시작했을 때 인간 노동자에 맞춰 공장 설비가 바뀐 것에 비유할 수 있다. AI를 위한 설계·재설계에는 다음과 같은 사례가 있을 수 있다.

• 탄탄한 학습 데이터를 가진 프로그래밍 언어를 선택한다.
• 특이한 구조 대신 관례적인 프로젝트 구조와 빌드 시스템을 쓴다.
• 더 많은 오픈소스 코드를 사용한다.
• 덜 인기 있는 프레임워크에서 더 인기 있는 프레임워크로 전환한다.
• 에이전트가 한 번에 읽지 못하는 함수나 파일은 분할한다.

스티브는 리액트를 쓸지 스벨트를 쓸지 계속 망설이다 결국 스벨트를 골랐는데, 학습 데이터가 풍부한 리액트 대신 스벨트를 쓰는 것은 분명한 도박이었다. 반대로 진은 클로저(상대적으로 덜 알려진 언어)를 놓아줘야 할지 걱정했지만, 큰 단점이 발견되지 않아 여전히 클로저로 코딩하고 있다 — 클로드 코드는 클로저 같은 언어라도 전문가 수준으로 코드를 작성해준다. 콘텍스트 윈도 한계가 사라지거나 AI가 모든 방언을 마스터하게 될 날이 올 수도 있지만, 그때까지 지금 할 수 있는 일은 묵은 관습을 AI에 맞게 재정비하고 거대한 함수를 리팩터링하는 것이다.

2.4 비용의 현실 — 프런티어 모델과 저렴한 대안 사이

AI 모델의 성능은 점점 좋아지겠지만, 저자들은 당장은 프런티어 모델만 주력으로 쓰고 있다. 다만 OSS 모델을 포함해 프런티어 모델을 바짝 뒤쫓는 다른 모델들도 있다는 것은 알아둘 만하다 — 앞서 다룬 메모리 관리 기법은 모델이 개선되고 콘텍스트 윈도가 커지더라도 계속 유효할 것이다.

현재 주요 프런티어 모델의 콘텍스트 윈도는 수십~수백만 토큰 수준이지만, 콘텍스트 윈도가 아무리 커지더라도 여전히 풀어야 할 문제가 하나 있다 — 비용이다. 회사 안 개발자 수백 명이 앞으로 출시될 프런티어 모델로 바이브 코딩을 하면 연간 수백만 달러의 비용이 들 수 있다. 스티브가 만약 매일 5개의 에이전트를 동시에 실행한다면, 당시 추론 가격 기준으로 연간 40만 달러를 지출해야 한다. 메모리 문제는 초프리미엄 모델에서는 해결될지 모르지만, 대부분은 성가신 메모리 제약을 기꺼이 받아들이며 더 저렴하고 더 작은 모델로 돌아가게 될 확률이 높다.

콘텍스트를 완전히 잃기 전에 문서 작성을 시키는 것과 같은 메모리 관리 전략은, 비용 문제 때문에 프런티어 모델이 아닌 다른 모델을 로컬에서 돌릴 때도 여전히 제 역할을 해낼 것이다. 모든 작업에 최고의 기술을 쓰는 것은 너무 비싸므로, 1~2년 뒤에 어처구니없어 보일지도 모를 기법을 지금은 어쩔 수 없이 감내하며 쓸 수밖에 없다. 콘텍스트 윈도 때문에 발생하는 제약과 우리가 지켜야 할 규율은 실제 작업의 FAAFO에 직접 영향을 미친다 — 바이브 코딩으로 빠르게 일하고 재미를 느낄 수 있지만, 지나치게 야심 차게 굴면 콘텍스트 한계·비용·인지적 한계에 부딪히고 만다.

2.5 2개 이상의 에이전트 동시에 다루기

채팅형 툴에서 코딩 에이전트로 전환하는 것은 또 다른 손을 얻는 것과 같다 — 앞으로 점점 더 많은 손을 얻게 될 것이다. 채팅형 AI 어시스턴트는 매우 동기적이며 지속적인 주의를 요구한다. 질문하고 응답을 기다리다 결과를 수동으로 적용하고 다시 질문한다 — 이렇게 작업하면 전속으로 달리는 여러 코딩 어시스턴트를 동시에 운영할 수 없다.

코딩 에이전트와 일하면 상황이 달라진다. 지속적인 주의를 요구하는 채팅 세션과 달리 에이전트는 대부분 비동기적으로 작동한다. 에이전트가 작업을 끝낼 때까지 기다리는 것은 지루한 일이므로, 곧 2개의 에이전트를 동시에 활용해 멀티태스킹을 시도하게 된다. 한 에이전트에게 작업을 맡기고 다른 곳으로 주의를 옮겼다가, 에이전트가 입력을 필요로 할 때만 돌아가 응답하고 다시 다른 프로젝트에 몰두할 수 있다.

멀티에이전트가 잘 작동하려면 각 에이전트가 가능한 한 서로 분리되어 독립적으로 활동할 수 있어야 한다. 이를 위한 준비는 세 가지다.

• 분리 — 병합 시 충돌을 피하기 위해 에이전트들이 코드베이스의 서로 다른 부분에서 작업하게 한다.
• 낮은 결합도 — 컴포넌트가 지나치게 밀접하게 연결되면 인터페이스 변경 시 문제가 발생할 확률이 높아진다.
• 명확한 인터페이스 — 컴포넌트 간 인터페이스를 잘 정의하면 독립적인 작업이 가능해진다.

멀티에이전트 바이브 코딩은 소프트웨어 개발 진화의 바로미터다 — 여러 프로젝트를 동시에 다루다 보면 전통적인 개발자 역할보다는 기술 리더나 디렉터에 더 가까운 역할을 수행하게 된다.

연습: 멀티에이전트 마에스트로 되기. ① 서로 다른 세션에서 2개의 코딩 어시스턴트를 설정한다(다른 터미널 창·다른 머신 등 무엇이든 좋다). ② 서로 다른 프로젝트나 리포지터리에서, 실제로 해결하고 싶은 난이도가 비슷한 두 가지 문제를 고른다(예: 한 에이전트는 버그 추적, 다른 에이전트는 새 기능 개발). ③ 두 에이전트 사이를 오가며 둘 다 바쁘게 돌아가게 하고, 한 에이전트가 바쁠 때 다른 에이전트로 전환해 작업 큐를 채운다. 한 번에 끝내지 않아도 되며, 현실의 멀티태스킹은 몇 시간·며칠에 걸쳐 이뤄진다. 마친 뒤에는 무엇을 배웠는지 되돌아본다 — 콘텍스트 스위칭이 활력을 준다는 사람도, 피로를 호소하는 사람도 있었다.

멀티에이전트를 돌리다 보면 자연스럽게 선호하는 워크플로 스타일로 기울게 된다 — 에이전트를 서로 분리하는 대신 하나의 프로젝트 안에서 여러 에이전트와 함께, 아마도 서로 다른 브랜치에서 작업하는 것을 선호하게 될 수도 있다. 이러면 병렬 작업 스트림의 생산성 이점을 유지하면서도 콘텍스트 전환에 따른 인지 부하를 줄일 수 있다. 격리되지 않은 공간에서 두 에이전트가 병렬로 작업하면 해결하기 까다로운 병합 충돌이나 조정 문제에 직면할 수 있는데, 시스템의 서로 다른 부분을 연결하는 최소 구현인 트레이서 불릿으로 컴포넌트 사이에 안정적인 인터페이스를 확립하면 이 문제를 완화할 수 있다(트레이서 불릿 자체는 §4.1에서 다룬다).

2.6 의도적으로 에이전트를 조정해 교차 오염 피하기

주방 한가운데에 공용 도마가 하나 있다고 가정해보자. 한 요리사가 생닭을 썰고 뒤처리 없이 그대로 가면, 페이스트리 담당 셰프가 그 도마 위에서 반죽을 민다. 공용 도마는 사용 후 항상 닦아야 한다는 명시적 규칙이 없거나 청소 담당이 너무 바쁘면 교차 오염 사고는 운이 좋아야만 피할 수 있다 — 이것이 주방에서 일어나는 경쟁 상태의 본질이다. 완전히 분리되어 있지 않은 상태에서 에이전트들에게 소프트웨어 개발을 맡기면 같은 상황을 맞닥뜨린다. AI 수셰프들은 작업 중에 같은 도마(파일, 함수, 포트 같은 시스템 자원, 설정 등)를 건드리기 때문에 미묘한 간섭이 생길 수밖에 없다.

이때 상호 의존적인 단계를 순차적으로 진행시켜, 다음 단계를 시작하기 전에 이전 단계를 완료시킬 수 있다. 인간은 작업 순서를 결정하고 에이전트들이 그 순서를 자동으로 지키게 하면 간섭을 어느 정도 예방할 수 있다. 그러나 2개 이상의 큰 작업이 동시에 코드베이스에 영향을 미칠 때는 상황이 훨씬 복잡해진다 — 예를 들어 애플리케이션 전반에 국제화를 적용하는 동시에 에러 처리 로직을 리팩터링하면, 두 작업 모두 사용자에게 노출되는 문자열을 수정하므로 충돌할 수 있다. 한 에이전트가 소스 파일의 모든 텍스트를 번역하고 동시에 다른 에이전트가 같은 파일에서 새 메시지를 추가하며 에러 처리 코드를 수정하면, 새로 추가된 메시지는 번역이 누락되거나 번역 때문에 코드가 깨질 수 있다. 요점은 변경 순서가 중요하고, 병렬 작업은 순서를 정하지 않으면 큰 혼란에 빠질 수 있다는 것이다.

조정 담당자로서 잠재적 충돌을 미리 예상해야 한다 — 모두가 기다리는 작업을 담당하는 에이전트가 끝내지 못했으면 일부 에이전트를 유휴 상태로 두고 기다리게 해도 좋고, 모든 에이전트가 병렬로 작업하도록 허용하되 병합 충돌을 미리 예상해 최대한 겹치지 않게 세팅하는 것도 방법이다. 상호 배제 전략을 쓰든, 경쟁 상황을 없애기 위해 시스템을 재분할하든, 조정 메커니즘을 만들든 방법은 자유이지만, 그 결정은 의도적이어야 한다. 잠재적인 경쟁 상태를 인식하고 워크플로를 조정하는 것은 헤드 셰프가 수행해야 할 핵심적인 역할이다.

2.7 에이전트들을 계속 바쁘게 하기

팀을 갖춘 후에는 당신이 다른 작업에 묶여 있는 동안에도 에이전트들을 모두 생산적으로 유지해야 한다. 바이브 코딩을 하다 보면 당신이 클릭하거나 프롬프트를 입력하기 전까지 에이전트들이 'Ready'를 깜빡이며 몇 시간이나 며칠까지 가만히 기다리는 상황을 자주 보게 된다. 스티브는 유휴 에이전트가 자꾸 생기자 이 문제를 AI에게 맡겨보았다 — AI는 답을 생성하는 것보다 검토하는 데 더 능숙하다는 점에서 효과가 있었다. 앤트로픽의 'Claude Code 베스트 프랙티스' 가이드도 "인간과 마찬가지로 클로드의 출력물은 반복을 거치면서 상당히 개선되는 경향이 있다. 첫 번째 버전도 괜찮지만 두세 번 반복한 이후에는 보통 훨씬 더 나은 결과가 나온다"고 강조한다.

에이전트에게 자신의 작업을 다시 살펴보고 테스트를 다시 실행하라고 하면, 작업이 사실상 전혀 끝나지 않았다는 사실이 드러나는 경우도 있다 — AI가 "빌드 완료했어요!"라고 하지만 정작 컴파일은 안 되거나, "테스트 통과"라고 하지만 테스트를 실제로 돌리지 않은 경우처럼. AI가 '완료'를 선언할 때는 모든 것이 잘 작동하리라 넘겨짚지 말고 AI에게 자기 비평을 시켜 문제점과 수정 사항을 찾아내야 한다. 다음은 에이전트를 쉬지 않고 돌릴 때 저자들이 자주 쓰는 프롬프트다.

• 모든 테스트를 다시 실행하고 실패가 있으면 보고하세요.
• 테스트 케이스를 개선하세요 — 코드와 테스트 케이스를 분석해 테스트를 개선해달라고 요청한다.
• 누락된 에지 케이스와 연관된 코드를 검토하세요 — AI는 자기가 만든 코드를 포함해 냄새가 나는 코드를 찾아내는 데 능하다. OpenAI 코덱스 팀은 "버그를 찾아서 고쳐라"를 추천 프롬프트로 제시한다.
• 첫 작업에서 끝내지 말고 반복하게 하세요 — 에러 처리·견고성·표준 관행·린팅 문제·포맷 일관성을 점검하게 한다. 시간이 부족하면 "더 낫게 만들어!"라고 외치고 자리를 떠도 된다.
• 의심스러운 모든 것을 요약하게 하세요 — 실패할 여지가 있는 모든 것을 찾아달라고 한다.
• 정리를 시키세요 — 임시 파일·브랜치·로그 구문·디버깅용 코드를 제거하고, untracked 파일은 커밋하거나 삭제해 깃이 추적하지 않는 파일이 남지 않게 한다.
• 지금까지 한 작업과 끝내지 못한 작업을 마크다운 문서에 요약하게 하세요 — 작업을 재개하거나 인계할 때 귀중한 자원이 된다.
• 문서와 프로젝트 산출물이 최신 상태인지 확인하세요.
• 코드에 담긴 해결법을 깨뜨리는 테스트를 하나 더 작성해달라고 요청하세요.
• 변경 사항을 정리하게 하거나 코드 리뷰용 문서를 준비하게 하세요 — diff 문서나 리뷰용 문서를 미리 만들어두면 다른 작업을 하다 돌아와도 콘텍스트 전환 없이 바로 점검할 수 있다.

스티브는 실제로 AI에게 자기 비평을 시켜 15~20% 더 많은 시간을 생산성 있게 썼고, 설익은 출력물을 검토해야 하는 지루함도 덜었다. AI에게 자신의 작업을 점검하라고 지시하는 것은 대체로 상황을 더 나쁘게 만들지 않는다 — 토큰만 더 소모할 뿐이며, 토큰은 시간과 주의력에 비하면 저렴하다.

3. 감지 — 폭발하기 전에 경고를 포착하기

교대 일정은 계속 바뀌는데 교대가 끝나면 모든 것을 잊는 수셰프들과 일할 때는 충돌 감지가 결정적인 역할을 한다. 내부 루프에서는 문제가 즉각적으로 드러나지만, 중간 루프에서 발생하는 문제는 폭발하기 전까지 며칠 혹은 몇 주 동안 숨어 있다. 먼저 에이전트 간 경합을, 이어서 작동은 하지만 이해할 수 없는 로직으로 가득 찬 괴물이 되어가는 코드 열화를 살펴본다.

3.1 에이전트 간 경합 감지하기

한 명이 일할 거라 예상하고 설계한 주방에 2개의 조리 스테이션을 두고 두 명의 수셰프를 데리고 운영해보면 다양한 문제가 발생한다 — "디저트는 네가, 애피타이저는 네가"라고 모듈화를 지시했음에도, 오븐을 두고 경쟁하거나 마지막 남은 버터에 동시에 손을 뻗거나 실수로 서로의 소스에 다른 양념을 칠 수 있다. 주방에서 경합이 발생한다는 것은 작업 공간 재구성이 필요하다는 신호다 — 여러 코딩 에이전트와 일할 때도 마찬가지다. 10명이 동시에 노트북 한 대를 쓰는 것과 같은 상황이라 작업 환경 재구성이 필요하다.

아무리 계획을 잘 세워도 계획대로 흘러가지 않을 때가 있다. §2.6에서 다룬 예방 조치가 도움이 되지만 모든 상호작용을 예측하는 것은 불가능하므로, 에이전트 간 경합이 더 큰 문제가 되기 전에 감지할 수 있어야 한다. 감지가 필요한 상황은 다음과 같다.

• 에이전트들이 동일한 파일을 수정하면서 발생하는 병합 충돌
• 여러 서버 인스턴스가 동일한 포트를 사용하면서 발생하는 포트 충돌
• 공유 자원 경합(데이터베이스, 파일, 서비스 등)
• 에이전트들이 실수로 동일한 브랜치에서 작업하면서 발생하는 브랜치 혼선

포트가 이미 사용 중이어서 서버가 시작되지 않는 경우처럼 문제를 즉시 알아차릴 수도 있지만, 프로젝트 수준에서 발생하는 미묘한 동시성 문제는 드러나기까지 몇 주가 걸릴 수 있다. 개발자 대부분은 다중 사용자 시나리오를 테스트하는 경우를 제외하면 인스턴스를 하나만 실행하며 개발하므로, 개발 환경과 워크플로 대부분은 여러 사용자(사람이든 AI든)가 동시에 쓰는 상황을 전제로 설계돼 있지 않다. 여러 에이전트가 열성적으로 여러 인스턴스를 띄우기 시작하면 이전에는 전혀 문제가 되지 않았던 충돌을 마주하게 된다. 충돌은 본질적으로 공유 자원에서 비롯한다 — 파일·포트·저장소·데이터베이스·메모리·CPU 등 공유 가능한 모든 것이 잠재적으로 에이전트 간 충돌을 만들어낸다.

AI와 각종 서비스·애플리케이션 사이에서 프록시 역할을 하는 MCP(9장 §3이 정의)는 에이전트 충돌에 새로운 전선을 만들고 있다. MCP 서버는 유용하지만, 동시 접속을 고려해 설계하지 않았거나 구현이 미흡하면 에이전트들이 서로의 발을 밟게 되는 계층을 하나 더 추가한다 — 여러 에이전트가 동시에 같은 MCP 서버를 쓰려 하면 스레드 안전성 문제·속도 제한 충돌·눈에 잘 띄지 않는 자원 고갈 문제가 발생할 수 있다. 에이전트 오케스트레이션이 복잡해질수록 감시해야 할 차원은 점차 늘어난다.

3.2 코드 열화 감지하기

모든 가전제품이 마치 러브크래프트 소설 속 괴물에 의해 작동하는 것처럼 보이는 상황 — 냉장고를 열면 가습기가 켜지고, 토스터는 제멋대로 불꽃을 튀기고, 믹서를 켜면 파스타 기계가 돌아가는 것 같은 비유클리드적 세계. 저자들도 이런 코드베이스를 겪었다 — 모든 움직임이 폭탄을 해체하는 것처럼 느껴지고, UI 코드 한 줄을 바꾸면 결제 모듈이 충돌하는 코드베이스 말이다.

진의 작가용 워크벤치 도구가 바로 이런 상황이었다(4장 §2.2 "엘드리치 호러 코드베이스"에서 다룬 같은 사건이다). 진은 특정 모델이 더 많은 응답을 생성하도록 기능을 추가하려 했는데, 클로드 코드가 이 기능을 구현하며 새로운 버그를 마구잡이로 쏟아내기 시작했다. 기능은 작동했지만 코드베이스는 모듈화와 거리가 먼 상태였다 — 모듈 경계도 없는 3000줄짜리 거대한 함수가 자리 잡아 이해도 변경도 불가능했다. 진은 AI가 중간 작업을 저장하려고 만든 함수의 인자 3개를 이해하는 데만 20분이 걸렸고, 10분 뒤에는 그것들을 기억하지도 못했다.

그날 진은 중요한 교훈을 얻었다 — 모듈화를 점검하지 않고 AI가 계속 코드를 덧붙이도록 두면, 시간에 비례해 모듈성 회복에 더 큰 노력이 필요하다는 것이다. 진은 사흘에 걸쳐 코드를 다시 작성했고(그중 하루는 손으로), 모듈 경계에 빌드 테스트를 추가하고 나서야 폭발물 처리반 같다는 느낌이 어느 정도 사라졌다. 이 사건을 계기로 진은 TDD를 거의 종교적으로 쓰기 시작했고, 별도의 창에서 테스트를 실행해 AI가 기존 기능을 깨뜨리는 즉시 알아챌 수 있는 프로세스를 구축했다.

7장 §3이 다룬 댄 스터티번트 박사의 통계 — 모듈화가 잘 안 된 복잡한 코드베이스를 다루는 엔지니어는 해고되거나 퇴사할 가능성이 9배 높다 — 를 명심해야 한다. 경계를 늦추면 필연적으로 그런 상황에 처하게 되며, 애초에 스스로 이런 상황에 빠지지 않도록 하는 것이 문제를 해결하는 가장 쉬운 방법이다.

4. 교정 — 재해 복구 프로세스

멀티에이전트 운영에는 명확한 재해 복구 프로세스가 필요하다. 문제가 생기면 즉각 해결하고, 망가진 워크플로를 재구축하고, 재발 방지 시스템을 강화해야 한다. 재해 복구는 트레이서 불릿 기법에서 시작해, 멀티에이전트의 생산성을 저해하는 반복 작업 자동화로 이어지고, 마지막으로 그 자동화 투자가 중간 개발 루프에서 만들어내는 경제적 배당으로 마무리된다.

4.1 트레이서 불릿으로 스트레스 테스트하기

유명한 음식 평론가가 레스토랑에서 식사한 뒤 식중독으로 병원에 실려 갔다고 가정해보자. 후행 지표만 담긴 보고서를 검토하거나 모든 직원을 한꺼번에 심문하는 대신, 평론가가 주문했던 것과 가장 유사한 주문을 의도적으로 주방 시스템에 흘려보내는 주방 라인 스트레스 테스트를 실시한다. 인수인계·준비 방식·플레이팅 절차를 관찰해 결정적인 실패 지점(조리 도구 미세척으로 인한 교차 오염)을 찾아낸다 — 전반적인 운영을 한꺼번에 검토했다면 결코 찾지 못했을 문제다.

이 접근법은 AI 어시스턴트와 일할 때도 귀중한 전략이 된다 — 이 장이 참조하는 트레이서 불릿(12장 §5가 소개)은 시스템 전체를 관통하는 완전한 경로가 실제로 동작함을 증명하는 최소한의 구현이다. 트레이서 불릿은 AI 어시스턴트가 실제 어려운 기술 도전 과제를 처리할 수 있는지 판단하는 데 도움을 준다 — 좁지만 완전한 한 단면에 집중해, 너무 많은 시간을 투자하기 전에 AI의 한계를 발견할 수 있다.

진이 작가용 워크벤치 프로젝트에서 터미널 인터페이스용 도구를 만들 때, 명령 실행에 어려움을 겪자 AI 어시스턴트에게 처음부터 다시 작업하도록 지시해 가능한 한 가장 단순한 트레이서 불릿을 만들었다 — "셸을 포크해 ls -a를 실행하고 그 출력을 화면에 보여주는 list라는 명령을 만들고 싶어"라는 프롬프트로 5분 만에 작동하는 코드를 손에 넣었다. 이 경험으로 진은 LLM을 사용해 초안 후보를 생성하는 명령어를 추가할 자신감을 얻었다.

스티브의 사례는 트레이서 불릿의 또 다른 측면을 보여준다 — 루비 스크립트를 코틀린으로 포팅하다 그레이들 설정 문제에 부딪혔을 때, 동일한 지점에서 계속 막히자 더 단순한 테스트 케이스(커맨드라인 인자를 출력하는 것)를 시도했다. AI가 이 단순한 케이스도 해결하지 못하자 스티브는 직접 운전대를 잡아야 할 시점이 왔다고 판단하고 전통적인 방법으로 구현을 시작했다. 스티브는 "트레이서 불릿은 AI가 난해한 그레이들 문제를 처리할 만큼 충분히 학습되어 있지 않다는 것을 증명한다"고 말했다 — 특정 과업에서 AI가 고전하는 모습은 그 영역에서는 AI를 써도 기계적 이득을 얻지 못한다는 명확한 신호로 받아들여야 한다.

4.2 워크플로 자동화에 투자하기

상당수 개발자는 워크플로 자동화에 투자함으로써 얻는 막대한 수익을 과소평가한다. 터미널·에디터·채팅 세션 사이를 끊임없이 오가며 콘텍스트나 명령·아웃풋을 복사·붙여넣기 해야 하는 던지기(슬링) 작업은 그 자체로 성가신 데다, 반복될수록 치명적인 병목이 되어 나쁜 영향을 누적시킨다. 복사·붙여넣기가 반복되면 다음과 같은 문제가 생긴다.

• 인지 흐름을 방해해 콘텍스트 전환을 강요한다.
• 미묘한 에러가 끼어들 기회를 만들어 문제가 연쇄적으로 커질 위험을 야기한다.
• 실험 사이클이 길어져 시간 비용을 증가시킨다.
• 성공적인 바이브 코딩의 토대인 빠른 반복을 저해한다.

현존하는 도구에는 여전히 많은 공백이 있어, 지금은 아직 "날카로운 칼은 있지만 전자동 믹서는 없는" 시대다. 그래서 여전히 터미널·셸 스크립트·마크다운 체크리스트·깃 브랜치를 오가며 작업할 수밖에 없고, 인지 부하를 낮추고 슬링 작업을 줄이려면 스스로 해결책을 마련해야 한다. 자동화로 던지기 작업을 줄일 수 있다면 언제든지 그렇게 해야 한다 — 저자들은 책 집필 과정에서 사소해 보이는 작업을 자동화하는 것이 연쇄적인 개선을 촉발한다는 사실을 경험했다.

개발자가 아닌 사람들은 새 기능을 만드는 일을 가장 대단하다고 생각하지만, 실제 개발자는 새 기능 구현보다 모호한 버그 리포트를 다듬고 백로그를 정리하고 티켓에 긴급도를 매기고 텔레메트리를 분석하고 문서를 업데이트하는 데 훨씬 더 많은 시간과 에너지를 쓴다 — 즐기는 개발자는 드물지만 반드시 해야 하는 이런 일이야말로 자동화하기 좋은 대상이다. 스티브는 구글 재직 시절 안드로이드 생태계 커뮤니티 버그 리포트를 매달 세 시간씩 분류했던 경험을 예로 든다.

저자들은 이 책을 AI와 함께 집필하며 처음에는 챗봇 안에서만 대화했는데, 정교하게 프롬프트를 구성하는 과정에서 던지기 작업량이 감당하기 어려울 만큼 많아져 새로운 채팅을 시작하는 것 자체를 피하게 됐고 하루에 많아야 다섯 번 정도만 챗봇을 실행했다. 이때 진이 프롬프팅 워크플로를 자동화하기 시작했다 — 처음에는 구글 독스 애드온으로, 이후에는 대화형 터미널 애플리케이션으로. 터미널 애플리케이션은 입력 표준화와 함께 대화 시작에 필요한 사전 절차를 줄여주었고, 대화 시작까지 걸리는 시간은 1분에서 1초로 줄었다.

4.3 옵셔널리티 경제학과 그 중요성

5장 §1이 인용한 OpenAI 직업 보고서의 저자 중 한 명인 대니얼 록 박사는 AI를 통해 워크플로를 자동화하면 믿기 어려울 만큼 높은 수익을 가져올 수 있다고 말했다 — 자동화 각각이 모이면 곱셈 효과 때문에 생산성이 누적으로 증폭되기 때문이다. 저자들은 3장 §6이 다룬 옵셔널리티를 정량화하는 공식을 여기서 제대로 짚는다.

        N × K
옵션 가치 ∝ ───── × σ
          t

• N — 모듈의 수
• K — 동시에 수행할 수 있는 실험의 수
• t — 하나의 실험을 수행하는 데 필요한 시간
• σ — 불확실성과 보상의 형태 및 크기

생성형 AI와 함께할 때 워크플로 자동화의 보상이 전례 없이 커지는 이유는 훨씬 더 많은 실험을 할 수 있고(K), 그 실험을 훨씬 더 빠르게 수행할 수 있기 때문이다(t) — 분자는 커지고 분모는 줄어들며 옵셔널리티의 가치가 크게 증가한다. 여기에 AI가 불확실성(σ)까지 크게 증폭시키므로 이전에는 상상할 수 없던 수준의 보상이 주어질 확률이 높아진다.

작가용 워크벤치 툴을 예로 들면, 저자들은 자동화에 투자해 t를 3분에서 1분으로 줄였고 병렬로 생성되는 초안 후보의 수를 40배 늘렸다 — 그 결과 옵셔널리티 가치는 120배 증가했다. 다양한 옵션을 만들어 탐색할 범위가 늘어나면 매우 큰 보상을 얻을 수 있지만, 그 성과는 연속적이 아니라 불연속적으로(계단식) 튀어 오르며 나타난다.

옵셔널리티가 가치를 내려면 조건이 하나 있다 — 변화 비용을 낮게 유지해야 한다. 켄트 벡의 사고 실험이 이 원리를 포착한다 — 동일한 기능·동일한 수익(매달 1억 달러)을 내는 두 소프트웨어가 있는데, 하나는 쉽게 수정할 수 있고 다른 하나는 그렇지 않다면, 변경할 수 있는 시스템이 더 가치가 높다. 변경할 수 없는 코드베이스의 옵션 가치는 거의 0에 가깝다. 저자들은 계속 강조해온 모듈식 아키텍처(7장 §3·이 장 §2.3)를 통해 코드베이스를 쉽게 변경할 수 있게 만든다 — 모듈식 아키텍처에서는 에이전트가 독립적으로 행동할 수 있고 안전하게 변경할 수 있어 N이 증가한다. 여기에 빠른 피드백 루프까지 더하면, 변경을 안전하게 수행하고 그 변경이 더 나은지 나쁜지 판단할 수 있다.

하버드 비즈니스 스쿨의 칼리스 볼드윈 박사는 모듈화의 이점을 이렇게 설명한다 — "소비자들은 모듈성이 확보되면 서로 다른 모듈을 믹스 앤드 매치할 수 있다. 시스템이 밀접하게 통합되어 있으면 '전부 아니면 전무'라는 상황에 묶이게 된다." 워크플로 자동화의 이득은 매우 크므로, 가장 무딘 칼부터 꺼내 개선을 시작해야 한다 — '이건 그냥 업무의 일부야'라고 체념한 채 반복해온 작업부터 자동화하고, 거기서 절약한 시간을 또 다른 자동화에 투자하는 것이다. 자동화 진입 장벽은 놀라울 정도로 낮고, 자동화 각각은 생산성이라는 나선형 계단을 한 칸씩 올라가는 것과 같다.

5. 결론

이 장은 에이전트와의 협업에서 발생할 수 있는 사고를 예방하고, AI 어시스턴트가 궤도를 벗어나거나 코드베이스를 망치고 있는지 감지하며, 이를 정밀하게 수정하는 중간 개발 루프의 핵심 실천법을 다뤘다. 장기적으로 에이전트를 오케스트레이션할 때 기억해야 할 핵심 실천 사항은 다음과 같다.

1. 골든 룰 문서화하기 — 절대 양보할 수 없는 원칙은 AGENTS.md에 성문화한다. 특히 '항상 해야 하는 것'과 '절대 해서는 안 되는 것'을 명시적으로 지시한다.
2. 수셰프에 맞춰 설계하기 — AI가 더 쉽게 보조할 수 있도록 코드를 구조화하고 적절한 도구를 쥐여준다. AI가 난해한 프레임워크나 거대한 단일 파일과 싸우게 만들지 않는다.
3. AI의 상태를 외부화하기 — 세션 종료 전 AI가 진행 상황·현재 계획·까다로웠던 부분을 기록하게 하고, 이 메모를 다음 세션을 안내하는 "문신"처럼 활용한다.
4. 여러 에이전트를 신중하게 활용하기 — 병렬 작업의 힘을 활용하되 작업 분리와 잠재적 병합 충돌을 신경 쓰며 조율한다. "서로 다른 요리는 서로 다른 스테이션에서" 원칙을 떠올린다.
5. 유휴 상태의 에이전트에게 지속적으로 일 시키기 — 완료를 주장해도 쉬게 하지 말고 스스로의 작업을 검토하고 테스트를 개선하고 에지 케이스를 찾으라고 다시 지시한다.
6. 트레이서 불릿을 사용해서 교정하기 — AI가 문제 해결에 어려움을 겪을 때는 문제를 최대한 단순화한다. 작고 성공적인 트레이서 불릿 하나로 상황을 정상 궤도로 돌릴 수 있고, 수제 코딩으로 전환해야 하는 시점도 알 수 있다.
7. 워크플로 자동화하기 — 반복 작업을 스크립트로 만드는 데 시간을 투자한다. 던지기 작업이 줄어들면 더 많은 실험이 가능해지며 FAAFO, 특히 옵셔널리티가 극적으로 올라간다.

다음 장(외부 개발 루프)에서는 시야를 더 넓혀 프로젝트의 전략적이고 장기적인 방향을 다룬다 — 수 주 또는 수개월에 걸친 바이브 코딩 작업을 어떻게 계획하고 실행할 것인지, AI의 도움을 받으며 프로젝트의 비전과 노력을 어떻게 일치시킬지, 가치를 어떻게 지속적으로 전달할지를 논의한다.

핵심 개념 정리

실무 체크리스트

• [ ] 이 프로젝트의 골든 룰(항상 해야 하는 것·절대 안 되는 것)이 AGENTS.md 같은 파일에 문서화돼 있는가?
• [ ] 콘텍스트 잔여량이 20~50%에 가까워질 때, 자동 압축이 실행되기 전에 AI에게 진행 상황을 문서화하라고 선제적으로 지시하는가?
• [ ] 세션을 끝내기 전에 메멘토 메서드(진행 상황·계획·까다로운 부분을 마크다운으로 외부화)를 습관적으로 실행하는가?
• [ ] 에이전트가 한 번에 읽지 못할 만큼 큰 파일(2500줄 이상)이 있다면, 모듈로 쪼갤 계획을 세웠는가?
• [ ] 2개 이상의 에이전트를 동시에 돌릴 때, 분리·낮은 결합도·명확한 인터페이스라는 세 조건을 갖췄는가?
• [ ] 여러 에이전트가 같은 파일·포트·브랜치·자원을 건드릴 가능성을 사전에 검토했는가?
• [ ] 에이전트가 '완료'를 선언했을 때, 곧바로 믿지 않고 테스트 재실행·자기 비평을 다시 지시하는가?
• [ ] AI가 특정 과제에서 계속 막힌다면, 더 단순한 트레이서 불릿으로 낮춰서 AI의 한계인지 직접 확인했는가?
• [ ] 반복되는 복사·붙여넣기(던지기 작업)를 자동화할 기회를 찾아보고 있는가?
• [ ] 이 코드베이스는 변화 비용이 낮은가 — 모듈식 아키텍처와 빠른 피드백 루프로 옵셔널리티의 전제 조건을 갖췄는가?

연습문제

1. 유형: 실무 시나리오. 3인 팀이 하나의 코드베이스에서 각자 다른 코딩 에이전트를 돌린다. 이 장의 골든 룰·AGENTS.md 논의를 근거로, 세 사람이 서로 다른 규칙을 가진 상태에서 발생할 수 있는 문제를 설명하고 해결책을 제시하라.
2. 유형: 판단. 콘텍스트 잔여량이 30%로 떨어진 상황에서 까다로운 리팩터링 작업이 절반쯤 진행 중이다. 이 장의 메멘토 메서드 원칙에 따라, 지금 무엇을 해야 하는지와 그 순서를 설명하라.
3. 유형: 분석. 팀의 코드베이스에서 2500줄이 넘는 파일 하나에 핵심 로직이 몰려 있고, 에이전트가 매번 grep으로 훑으며 작업한다. 이 장의 '공장 재설계' 원칙을 근거로 무엇이 문제이며 어떻게 접근해야 하는지 분석하라.
4. 유형: 비교. 에이전트 간 경합(§3.1)과 코드 열화(§3.2)는 둘 다 '감지'의 대상이지만 성격이 다르다. 두 문제가 겉으로 드러나는 방식과 발견까지 걸리는 시간의 차이를 비교하라.
5. 유형: 실무 시나리오. 팀에서 반복되는 수동 작업(예: 배포 전 체크리스트 확인)이 있다. 이 장의 N·K/t·σ 공식을 근거로, 이 작업을 자동화했을 때 옵셔널리티가 어떻게 늘어나는지 설명하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 수동 관행으로 소개한 메멘토 메서드·AGENTS.md는 그 뒤로 공식 기능·업계 표준으로 제품화됐다. 이 장의 핵심 서술(세션이 바뀌면 AI는 모든 것을 잊는다·그래서 예방·감지·교정이 필요하다)은 여전히 유효하다.

• AGENTS.md, 관행에서 Linux Foundation 표준으로. 이 장 §2.1이 "코딩 에이전트용 AGENTS.md 파일(또는 그에 상응하는 것)"이라 부르며 아직 굳어지지 않은 관행으로 소개한 형식은, 그 뒤 OpenAI가 Agentic AI Foundation(AAIF)에 기증하며 Linux Foundation 산하 표준이 됐다 — 60,000개 이상의 저장소, 20개 이상의 도구(Codex·Cursor·Copilot·Gemini CLI·Aider 등)가 네이티브로 읽는다. "모든 가이드라인과 규칙을 이런 파일에 정리하라"는 이 장의 조언은 특정 벤더의 임시방편이 아니라 업계 공통 관례가 되는 방향으로 실현된 셈이다.
• 메멘토 메서드·압축이 수동 프롬프트에서 공식 API 기능으로. 이 장 §2.2가 "우리가 지금까지 했던 모든 작업의 진행 상황과 계획을 마크다운 파일에 적어줘"라는 수동 프롬프트로 설명한 관행은, Claude 공식 문서의 메모리 도구(Memory tool)와 압축(Compaction) API로 제품화됐다. 압축은 이제 토큰 임계치에서 서버 쪽이 자동으로 대화를 요약해 압축 블록으로 남기고, 다음 요청에서 그 이전 내용을 정리한다 — 이 장이 "실수로 자동 압축이 실행되지 않도록 주의하라"고 경고했던 위험(중요한 콘텍스트 유실)을 instructions 옵션으로 무엇을 보존할지 지정하는 방식으로 완화한다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• Best Practices for Claude Code(공식 문서) — code.claude.com/docs/en/best-practices
• AGENTS.md 공식 사이트 — agents.md
• Linux Foundation — Agentic AI Foundation(AAIF) 결성 발표 — linuxfoundation.org 공식 보도자료
• Claude 메모리 도구(Memory tool) 공식 문서 — platform.claude.com/docs
• Claude 압축(Compaction) API 공식 문서 — platform.claude.com/docs

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) §2.1에 따르면 규칙은 각자의 머릿속에 있는 한 서로 다를 수밖에 없고 AI는 마음을 읽지 못한다. 세 사람이 각자 다른 규칙으로 같은 코드베이스에 에이전트를 돌리면, 한 에이전트가 지킨 관례(예: 특정 에러 처리 방식)를 다른 에이전트가 위반해 일관성이 깨지고 리뷰 비용이 늘어난다. 해결책은 팀 공용 AGENTS.md에 "항상·절대" 골든 룰만 정제해 문서화하고, 개인 취향은 그 파일 밖에 두는 것이다 — 규칙이 길어질수록 준수율이 떨어지므로 최소 집합만 공유한다.
2. (문제 2 정답) §2.2의 메멘토 메서드에 따르면, 자동 압축이 실행되기를 기다리지 말고 지금(잔여량 30%) 선제적으로 AI에게 "지금까지의 진행 상황과 계획을 마크다운 파일로 적어달라"고 지시해야 한다. 그런 다음 그 문서에 빠진 세부 사항이 없는지 검토하고 채워 넣은 뒤에 압축을 진행하거나 콘텍스트를 비운다. 순서를 바꿔 압축이 먼저 일어나게 두면 리팩터링의 절반이 담긴 세부 맥락이 유실될 위험이 있다.
3. (문제 3 정답) §2.3에 따르면 문제는 파일이 너무 커서 에이전트가 전체를 읽지 못하고 grep으로 훑는다는 점이다 — 이는 AI를 거슬러 코딩하는 상황이다. 진의 사례(2500줄 파일을 여러 모듈로 재배치)처럼, 핵심 로직을 명확한 인터페이스를 가진 더 작은 모듈로 분할해 에이전트가 관련 코드 전체를 한 번에 읽을 수 있게 재구성해야 한다.
4. (문제 4 정답) 에이전트 간 경합(§3.1)은 포트 충돌처럼 즉시 드러나는 경우도 있지만 병합 충돌·브랜치 혼선처럼 몇 주가 걸리기도 한다. 코드 열화(§3.2)는 처음엔 기능이 정상 작동하는 것처럼 보이다가, 새 기능을 추가하려는 순간에야 3000줄짜리 함수처럼 이해·수정이 불가능한 상태가 드러난다 — 경합은 "충돌"이라는 사건으로 드러나지만 열화는 "더 이상 다룰 수 없다"는 누적된 상태로 드러난다는 점이 근본적인 차이다.
5. (문제 5 정답) §4.3의 N·K/t·σ 공식에서, 배포 전 체크리스트 확인을 자동화하면 하나의 실험(배포 시도)에 드는 시간 t가 줄어든다. t가 줄면 같은 시간 안에 K(동시에 시도할 수 있는 실험 수)를 늘릴 수 있고, N·K/t가 커지면서 옵션 가치가 증가한다 — 여러 배포 후보나 롤백 전략을 더 값싸게 병렬로 시도해볼 수 있게 되는 것이 곧 옵셔널리티의 증가다.